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Abstract — The National Aeronautical and Space 
Administration (NASA) recently launched a new software 
defined radio research test bed to the International Space 
Station. The test bed, sponsored by the Space 
Communications and Navigation (SCaN) Office within 
NASA is referred to as the SCaN Testbed. The SCaN 
Testbed is a highly capable communications system, 
composed of three software defined radios, integrated into a 
flight system, and mounted to the truss of the International 
Space Station. Software defined radios offer the future 
promise of in-flight reconfigurability, autonomy, and 
eventually cognitive operation. The adoption of software 
defined radios offers space missions a new way to develop 
and operate space transceivers for communications and 
navigation. Reconfigurable or software defined radios with 
communications and navigation functions implemented in 
software or VHDL (Very High Speed Hardware Description 
Language) provide the capability to change the functionality 
of the radio during development or after launch. The ability 
to change the operating characteristics of a radio through 
software once deployed to space offers the flexibility to 
adapt to new science opportunities, recover from anomalies 
within the science payload or communication system, and 
potentially reduce development cost and risk by adapting 
generic space platforms to meet specific mission 
requirements. The software defined radios on the SCaN 
Testbed are each compliant to NASA’s Space 

Telecommunications Radio System (STRS) Architecture. 
The STRS Architecture is an open, non-proprietary 
architecture that defines interfaces for the connections 
between radio components. It provides an operating 
environment to abstract the communication waveform 
application from the underlying platform specific hardware 
such as digital-to-analog converters, analog-to-digital 
converters, oscillators, RF attenuators, automatic gain 
control circuits, FPGAs, general-purpose processors, etc. 
and the interconnections among different radio components. 

NASA is inviting experimenters from industry, academia, 
and other agencies to use the SCaN Testbed. On the flight 
system, the three software defined radios (SDR) and a 
portion of the flight computer or avionics, is available to 
experimenters to develop, test, and operate new SDR 


applications in-orbit. Experiment operations include in- 
flight reconfiguration of the SDR waveform functions, and 
communications at S-band or Ka-band with NASA’s in- 
space Tracking and Data Relay Satellite Network, or at S- 
band direct from the SCaN Tested to any Earth -based 
compatible ground station. One of the SDRs also receives 
GPS frequencies at the LI, L2c, and L5 frequencies. 
Various GPS waveforms are possible using the 
reconfigurable digital processing of the SDR. Command, 
control, and experiment operations occur from the Glenn 
Research Center in Cleveland, Ohio. NASA provides the 
ground connections between the Experiment Center and the 
uplink site to the TDRSS Network at White Sands. New 
Mexico. 

Experimenters are encouraged to use the SCaN Testbed for 
a variety of research topics and applications. NASA will 
provide access and support to both the on-orbit testbed, and 
ground-based systems for development and verification 
activities. This paper will provide a description of the SCaN 
Testbed, the SDR capabilities, and the ground systems 
available to potential experimenters. Unique aspects of 
SDR developments, verification, and operations will be 
discussed. 
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1. Introduction 

The flexibility offered by software defined radios (SDRs) 
offer space missions new capability during the development 
and on-orbit phases to conduct and return more science. 
While the SDR provides this flexible capability for 
communications functions, navigation functions, and even 
networking functions of the mission, it also involves 
considering the way operations is viewed and conducted 
when using the SDR. 

Software defined radios have emerged over the last decade 
as a viable approach to space communications. SDRs are 
capable of changing their characteristics through 
reprogrammable signal processing elements such as field 
programmable gate arrays (FPGA), or other technologies 
such as general purpose and multi-core processors. While 
SDRs have been considered or used in military domains [4], 
public safety [5], and cellular systems, SDRs are just 
beginning to emerge for space missions [6, 7]. 

Over the last 10-15 years, NASA has launched four 
missions and one demonstration carrying software defined 
radios. The Mars Reconnaissance Orbiter (MRO) [6], the 
Communication and Navigation Demonstration on Shuttle 
(CANDOS) [8], the Lunar Reconnaissance Orbiter (LRO) 
[7], and most recently the Curiosity (Mars Science 
Laboratory-MSL) and Mars Atmosphere and Volatile 
Evolution (MAVEN) each use an SDR as part of the 
mission. The MRO mission provides relay communications 
between Mars proximity surface rovers and Earth. Curiosity 
is a rover on the surface of Mars since 2012 and MAVEN is 
study the thinning of the Mars atmosphere and the 
disappearance of surface water over time. 

MRO, MSL, and MAVEN all use a version of the Electra 
Ultra High Frequency (UHF) Transceiver. The Electra SDR 
is a fully reconfigurable, frequency-agile transceiver 
operating in the 390-450 MHz Ultra High Frequency (UHF) 
band. Future missions such as ESA Exobiology on Mars 
(ExoMars) and the Mars 2020 lander under development at 
Jet Propulsion Lab (JPL) are also planning to carry an 
Electra, as well as a newer Universal Space Transponder 
(UST) SDR which supports both X-band deep space 
communication and UHF proximity communications. The 
core of the Electra SDR is the baseband processor module 
(BPM), a flight-reprogrammable subsystem offering 
digitally implemented modulation and demodulation 
functions, standardized link layer protocols, and interfaces 
with the spacecraft avionics. This software defined radio 
BPM incorporates two key reconfigurable elements: a 
payload controller based on a SPARC 32-bit micro- 
processor and a modem processor utilizing a lMgate Xilinx 
reprogrammable Virtex FPGA. In addition, the baseband 
processor includes several radiation hard, one-time 
programmable FPGAs, along with a substantial amount of 
dynamic and static memory. 

CANDOS was an SDR experiment run from the payload 


bay aboard a Space Shuttle flight. The experiment flew a 
Low Power Transceiver (LPT) SDR. The radio transmits 
and receives S-band bidirectional communications with 
TDRSS and receives GPS L1/L2 signals. Like other SDRs, 
the central part of the radio is the digital signal-processing 
module. The digital module hosted two Virtex 11-6000 
FPGAs, a Analog Devices DSP chip, memory for program 
storage, clock synthesis and distribution circuitry and 
various data transceivers. 

The LRO mission was a lunar surface-mapping mission 
using a SDR for the radar waveforms. The LRO transceiver 
consists of analog receiver, digital receiver, quadrature 
digital waveform synthesizer, analog exciter, power 
amplifier, and control processor modules. The digital 
receiver and quadrature digital waveform synthesizer 
(QDWS) enable the flexibility and reprogrammability by 
implementing radar waveforms in Xilinx FPGAs. The Rad 
750 control processor collects and reports telemetry to the 
spacecraft host, controls and configures the radio (and 
payload), and provides a router for radar data from the 
receiver to the spacecraft host electronics. The radio 
operates in the S-band and X-band. 

To further expand the applicability of SDRs, reduce the 
perceived risk of using SDR technology, and understand 
SDR developments, operations, and performance in space; 
NASA has designed, built, launched, and installed a SDR- 
based communication system on the International Space 
Station, referred to as the Space Communication and 
Navigation (SCaN) Testbed. 

The SCaN Testbed System consists of both a space flight 
element and ground control center used for operations. The 
SCaN Testbed provides a unique opportunity for researchers 
to investigate a host of different architectures and SDR 
applications in the environment of space using a complete 
end-to-end communication system. The use of SDRs as the 
radio platform of the SCaN Testbed provides a flexible and 
adaptable means to test a variety of communications, 
navigation, and networking protocols, and signaling 
schemes within an actual mission experience in the space 
environment. This unique opportunity is intended to expand 
the knowledgebase of SDR system users and provide 
mission managers with the information they need to reduce 
risk and cost to future science missions. 

The goals of the project include demonstrating a seamless, 
interconnected, and autonomous end-to-end space network. 
The envisioned network will increase utilization over 
existing architectures, allows the flight system to perform 
functions currently performed on the ground such as 
scheduling link services and calculate spacecraft antenna 
pointing angles, adjust data rate, modulation, and error 
correction coding in response to channel conditions, 
automatically re-establish disrupted links, and route data 
according to priority and link conditions, among other new 
features. These new capabilities represent significant 
advancements in NASA’s space networks. Enabling these 
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advancements is the use of SDR technology. The SDR 
technology includes more than just the hardware platforms. 
SDR technology includes the platforms, software 
infrastructure, software applications, verification methods, 
and operations. Software infrastructure might include an 
operating environment to abstract the application software 
such as STRS [TBD] or for terrestrial military radios, the 
Software Communications Architecture (SCA) [TBD]. It 
might also include radio services such as temperature 
compensation circuits for receive or transmit functions, 
power amplifier control or protection, file services or other. 
Software applications also include more than typical modem 
functions such as modulation or encoding. These 
applications might include data formatting, link layer 
framing (e.g. using the Consultative Committee for Space 
Data Systems Advanced Orbiting System (AOS)), 
networking layers including Internet and disruptive tolerant 
networking protocols (IP and DTN). For integration and 
operations, the Testbed provides opportunity to better 
understand the activities associated with using SDRs. From 
new SDR software development, pre-flight verifications 
with ground hardware, software uploads to the flight 
system, and eventual over-the-air operations, use of the 
Testbed by NASA and outside experimenters is an all- 
inclusive view of this important technology maturing to the 
state sufficient for routine use in space. 

2. Flight System 

The flight element is a fully space qualified communication 
system, pictured in Figure 1. The flight system consists of 
three software defined radios, each connected through an RF 
subsystem to the antennas. All subsystems are controlled 
from a flight computer referred to as the avionics. All the 
major elements of the flight system are housed within the 
main enclosure in the picture, with only the antennas visible. 

Pictured in Figure 2, the flight element is installed on the 
truss of the International Space Station (ISS). From this 
location, the flight element communicates to NASA’s White 
Sands Ground Complex via the Space Network of Tracking 
and Data Relay Satellite System (TDRSS), or direct 
communications with a ground station visible to the ISS 
orbit. Communications with TDRSS may occur at S-band 
or Ka-band frequency. 



Figure 1 - SCaN Testbed Flight System 


Communications direct with the ground occurs at S-band. 
The flight system also has a GPS antenna connected to one 
of the SDRs. The SDR can receive signals in the L-band, at 
and near the GPS frequencies of LI, L2, and the new L5. 
The remaining flight system components include the RF 
subsystem consisting of RF switches linking each S-band 
SDR to each S-band antenna. The Ka-band portion of the 
RF subsystem includes a Ka-band traveling wave tube 
amplfiier, and signal conditioning circuitry. 



Figure 2 - SCaN Testbed Location on ISS 


3. Ground System 


There are two paths to access the SCaN Testbed while on- 
orbit on the ISS. The first path is NASA’s ISS payloads’ 
command and control path through the Payload Operations 
Integration Center (POIC) located at the Marshall Space 
Flight Center in Huntsville, Alabama. The path, shown in 
Figure 3 is from the SCaN TesBed Control Center to the 
payload through the POIC, is the primary command/ 
telemetry path to the TestBed. This path uses the ground 
infrastructure between POIC and WSC and the 
communication system on-board ISS established for all ISS 
experimenters to access experiment systems on-board ISS. 
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The second path to communicate with the Testbed, is 
through the over-the-air experiment communications path 
from the experimenter to the software defined radios on- 
board the flight system. The experiment path is the main 
experimenter path to the SDRs, and illustrated in Figure 4. 

Most experiments use the path through the SCaN Testbed 
Experiment Center (STEC) which provides a data interface 
to the TDRS and on to WSC. Some experiments may use 
experimenter provided communications terminals (e.g. a 
rooftop antenna at the experimenter location). The path 
from the Testbed to the Experiment Center begins at the 
Testbed from 1) within the SDR, 2) the avionics, or 3) 
incoming data on an experiment path routed back out on a 
second experiment path. From the SDR, the signal goes 
through the flight RF subsystem, through a user specified 
antenna (e.g. low gain or high gain) and communicates to a 
Tracking and Data Relay Satellite (within the Space 
Network) which serves as a “bent-pipe” relay satellite to a 
ground terminal at White Sands Complex or direct to a 
ground station. The White Sands Complex is one of the 
major downlink sites for satellites within NASA’s Space 
Network System. The current operational configuration 
provides standard SN legacy services (modem, coding and 
other baseband bit handling), and a user programmable SDR 
is scheduled for installation at WSC. From the White Sands 
ground terminal, an experimenter may access either legacy 
services provided by the ground terminal (e.g. modem, 
baseband framing, network routing) or use a SCaN Tetsbed 
Project provided software defined radio to implement a 
custom application provided by the experimenter. The 
SCaN Testbed ground-based SDR provides the modem, 


baseband, and network routing functions for the 
experimental link, not supported by the legacy ground 
terminal services. 

Once the data reaches the network routing stage, the 
experiment uses NASA’s ground network to link the data to 
the SCaN Testbed Control Center and Experiment Center at 
Glenn Research Center. The Control Center routes 
experiment data to the Experiment Center for final reception 
and processing by experimenter provided hardware (as 
needed). At the Experiment Center, the experimenter also 
has access to operational information such as flight system 
telemetry, SDR telemetry, TDRS link parameters (e.g. BER, 
C/No), and 1SS position and attitude information. The 
Control Center also provides a remotely accessible database 
of telemetry which can be retrieved by experimenters. 


4. Flight Software Defined Radios 

Within the flight system are three software defined radios. 
The software defined radios each provide a different 
capability to the experimenter. One SDR built by General 
Dynamics Corporation, transmits and receives in NASA’s 
near-Earth S-band allocation. The second SDR built by Jet 
Propulsion Laboratory and L3 Cincinnati Electronics, also 
supports transmit and receive at S-band and also receives L- 
band GPS signals. The third SDR build by Harris 
Corporation, operates at the 22/26 GHz Ka-band allocation. 
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Figure 3 - Primary Command/Telemetry Path Ground System 
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Figure 4 - Experiment Data Path Ground System 


All three SDRs share a similar internal architecture. At the 
core of each SDR are a general purpose and signal 
processing module consisting of a general purpose 
processor, one or more reconfigurable FPGA’s, and memory 
to store and run software, as well as (depending on the 
waveforms instantiated in the SDR) storing data that is 
being carried over the RF links. The remaining modules in 
each SDR include RF transition from the signal processing 
module to the power amplifier and receiver/low noise 
amplifier front end. Each SDR also interfaces to the 
payload avionics computer with both command/telemetry 
and data interfaces. 

Each SDR is compliant to NASA’s Space 
Telecommunications Radio System (STRS) [9]. Over the 
last several years, NASA has been developing STRS as a 
common architecture for SDRs. The STRS Architecture 
provides an abstraction between the radio platform hardware 
and the waveform applications. STRS allows NASA to 
successfully apply software defined radio technology in a 
common way across missions while preserving the unique 
implementations necessary to meet specific mission needs 
by developing radios that are based on an open architecture 
standard. An open architecture standard promotes the use of 
published, well defined interfaces that enable different 
vendors to provide radios that conform to the interface 
standard thus providing commonality among different 
implementations and enabling interoperability between 
providers of different software elements. Platform 
providers abstract hardware interfaces so as to work with 
waveform applications from different developers. Standard 
interfaces provide flexibility for component replacement, 
technology insertion, and risk reduction through standard 
software component reuse. Standards promote the growth 
of a large base of domain experts; agency personnel. 


software and hardware providers, and the user and 
operations communities, all knowledgeable of the common 
standard. NASA’s goal in developing the STRS standard is 
to simultaneously capture the benefits of SDR technology 
and the economies and benefits of an open architecture 
standard. 

Each Testbed SDR is compliant to the STRS Architecture, 
version 1.02.1. Each SDR provider delivered an operating 
environment, which included an abstraction layer for 
hardware interfaces and the required documentation for 
future waveform developers. In addition to the STRS 
compliant infrastructure platform software, GD and Flarris 
also provided application waveforms to support an initial 
capability with Space Network Users Guide (SNUG) 
compatible modulation with their SDR, also compliant with 
the STRS Architecture. JPL provided a set of sample 
waveform applications to allow characterization and 
demonstration of the hardware platform, as well as an 
example for waveform developers. The Glenn Research 
Center teamed with Goddard Space Flight Center to provide 
a SNUG compatible waveform application for the JPL/CE 
SDR. This was the first time a waveform developer 
different from a platform developer provided a waveform, 
exercising the STRS Architecture interfaces and principles. 
While there were some dependent aspects on the particular 
abstraction infrastructure software, much of the waveform 
was developed in parallel with the radio which was enabled 
by the pre-defined STRS software interfaces. 
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5. An Experiment 

An experiment using the SCaN Testbed can vary depending 
on the objectives. Experimenters may use existing 
capabilities of the Testbed in new ways, or provide new 
hardware or software for integration into the SCaN Testbed 
System. 

Experimenters may develop experiments by adding 
software/firmware and/or hardware in various places within 
the SCAN Testbed System, illustrated in Figure 5. The 
overall system consists of the Testbed aboard ISS, the 
External Systems of White Sands or a direct to ground Earth 
station, the SCaN Testbed Ground System and finally the 
Experiment Center. 



= Experiment Element (e.g. sw, fw, or hw component' 
Figure 5 - Experimenter Access Points 


Each star of Figure 5 represents locations where software 
functions or hardware may be provided by experimenters 
within the system. Software/ firmware can be installed and 
operated on the flight system software defined radios and/or 
avionics. On the ground, software/firmware can be installed 
and operated on the SDR at the White Sands Complex. 

An experiment could be a new waveform application 
installed on one of the SDRs communicating with the 
legacy services of the Space Network through a TDRS. 
This would entail the experimenter developing, testing, and 
providing the new firmware to the mission operations team 
for upload to the flight system. Alternatively, an 
experimenter could provide unique application software in 
the avionics, and use an existing waveform for the SDR link 
to the ground. Experimenters may also provide unique 
experiment hardware at either a ground station, at the SCaN 
Testbed Experiment Center , or even a separate flight node 
such as a cubesat and use SCaN Testbed as a relay satellite 
or another space node of the network. Hardware at the 
Experiment Center may send and receive directly with the 
data stream to the flight SDRs (via WSC) through the SCaN 
Testbed Control Center interface. Experimenters have the 
option to define their experiment and provide the hardware 
and/or software as they need for their experiment. 


As an example, let’s consider the SDR technology 
advancement experiments of the Glenn Research Center. 
The objective of these experiments is to advance the SDR 
platforms to Technology Readiness Level 7 (operation in 
the space enviromnent, in a system configuration), 
characterize the launch waveform performance on-orbit, 
understand the operational aspects of multiple SDR 
waveform and application reconfigurations, and develop 
new platform services or applications to use the SDR to 
characterize the space environment effects on SDRs. 

For these experiments, the experimenter provided the legacy 
TDRS waveforms that reside on each of the SDRs. Glenn 
Research Center and Goddard Space Flight Center teamed 
to develop the waveform on the JPL SDR, while Harris and 
GD provided the waveforms for their respective SDRs, to 
support the experiment. At WSC, the legacy 
receivers/modems are used for modulation and 
demodulation functions. In addition to the WSC provided 
hardware, the GRC experimenter provides a front end 
processor (EFEP), for higher layer functionality baseband 
processing (reference Figure 6). The EFEP creates (transmit 
side) and removes (receive side) a portion of the SDR 
waveform processing of the experiment data. The EFEP 
firmware can generate test data or read from files to provide 
a transmit bit stream through the SCaN Testbed system with 
a number of different bit patterns and at a variety of data 
rates. The experimenter controls the selection of waveform 
characteristics such as framing, randomization (or 
scrambling), and forward error correct (FEC) coding applied 
to the data if called for by the experiment configuration. 
The EFEP can also receive experiment data from the SCaN 
Testbed system and remove these waveform characteristics 
to restore the user data. In this example, the experimenter 
provided both the hardware and software for the experiment 
[ 12 ]. 



Figure 6 -Experiment 
Hardware/Software Example 


Figure 6 illustrates a functional diagram of the experimenter 
provided front end processor and the clock and data 
interface between the experimenter provided hardware and 
the SCaN Testbed Control Center. The experiment 
hardware is also equipped to accommodate commercial bit 
error rate test equipment, data storage, and a network 
interface. This example experiment hardware is expected to 
be more extensive than typically provided hardware since 
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the Glenn Research Center will reuse the hardware for a 
number of different experiments. 

Other early experiments include an S-band and Ka-band 
IPv4 On-board Routing/Relay Experiment to demonstrate IP 
routing between a ground and on-board network using one 
or more Ka/S-band point-to-point sub-networks formed by 
TDRSS legacy waveform and IP gateways available at 
launch. This experiment will demonstrate application data 
routing between ground hosted and on-board hosted 
applications over various IPv4 sub-networks. The IP 
applications are isolated from data link changes by the IP 
layer, thus various waveforms with different data rates or 
data format characteristics can be used, such as those 
provided by the launch waveform experiment EFEP, shown 
in Figure 6. The routing/relay applications do not have to be 
modified as new SDR waveforms or better data links are 
introduced (IP on radio). 

Another early experiment is GPS navigation at the LI, L2, 
and L5 frequencies. GPS LI signals have been used by 
LEO satellite systems for navigation for a number of years. 
The SCaN Testbed adds the new L5 and L2c signals and 
provides a unique capability to modify on-orbit algorithms 
and assess performance at LI, L2, and L5. This particular 
GPS experimenter, the Jet Propulsion Laboratory, has 
developed the software (both CPU and FPGA code) 
required to receive L-Band GPS signals on the JPL SCaN 
Testbed SDR, to provide real-time precise positioning of the 
GPS antenna on the SCaN Testbed and compare with the 
known ISS position solution. As new GPS services are 
enabled, new GPS waveforms can be implemented and 
verified on the flight system by any experimenter. This 
GPS experiment will also use ground processing to 
determine the ISS orbit, calibrate the ionosphere effects 
using the at least two GPS frequencies and characterize the 
multipath environment at the GPS antenna on the SCaN 
Testbed. 


6. Ground-based Development System 

Once an experimenter’s proposal is submitted, reviewed and 
selected by the Experiment Board, experimenters will have 
access to several SCaN Testbed project ground based 
systems for development and verification of their 
experiment software. GRC and JPL provide testbeds with 
radio prototypes or breadboards. There is also a high 
fidelity replica of the entire flight system at GRC containing 
Engineering Model (EM) copies of the flight articles, 
referred to as the Ground Integration Unit (GIU). 

The GRC Experiment Development System (EDS) is a 
collection of SDR breadboards and associated test 
equipment intended to provide initial opportunity for 
software testing and basic functional validation. The EDS 
equipment provides a basic emulation of the hardware and 
software of the SCaN Testbed flight system. Configuration 


control of the EDS is not as formal as the GIU and thus 
affords more of the laboratory development work 
environment. 

Experimenters may access the EDS physically at NASA’s 
Glenn Research Center or through a remote connection. In 
person use of the SDR breadboards may provide additional 
test points depending on the final remote access design. 
Remote access to the breadboards will save travel time and 
expenses for experimenters. In either case, project 
personnel will assist experimenters in the lab or using the 
remote connection to the hardware. JPL also provides a 
remotely accessible prototype testbed for the JPL-SDR. An 
important difference between the JPL testbed and the GRC 
EDS is that there is no avionics at JPL, so experimenters are 
working directly with the radio’s command, telemetry, and 
data interfaces. 

The GIU is a high fidelity version of the SCaN Testbed 
flight system. The GIU is used for both experiment 
software development and for more controlled final 
development testing and verification testing. Because of the 
high fidelity of the GIU, it is also used by the SCaN Testbed 
Mission Operations team for mission training and flight 
operations anomaly resolution. Due to the limited EDS 
capability, in some cases the experimenter may initiate 
ground test exercises on the GIU and corresponding support 
systems (i.e. bypassing using the EDS capabilities). Figure 
7 illustrates the development process [10]. 



Figure 7 - Experiment Development Process 

Experimenters may access the GIU physically at Glenn. At 
this time there is not a remote connection planned to the 
GIU. Project personnel will assist experimenters on-site 
using the GIU. 

Generally, experimenters will develop and operate their 
experiment with no cost to NASA. Experimenters have 
access to NASA personnel, ground development systems, 
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and the flight system. However, experimenters may request 
from NASA additional, specific support for their experiment 
which may result in reimbursement to NASA, but this is a 
unique situation determined at the start of the experiment 
discussion. Experimenters will be allotted time and 
support from the project depending upon the number of 
experimenters and available project resources. Every effort 
will be made to accommodate experimenter’s time with the 
system. 


7, Flight Software 

Software developed for the Testbed is subject to the NASA 
Procedural Requirements (NPR) Software Engineering 
Requirements 7150.2 [11] processes and procedures for 
developing space flight software. This entails creating 
certain plans, documenting requirements and designs, 
verifying operations, and performing certain code and 
project reviews. Experimenters are expected to conform to 
the intent of the NASA standards, but may use their own 
processes, if they align with the standard. The experiment 
plan will document the differences. An essential distinction 
in the level of process rigor is the NASA software class, 
which is different for software that will run on the avionics 
and that which will run on the SDRs. 

Software can be placed on either the avionics or software 
defined radios. Software on the avionics performs a number 
of functions for experiments in addition to safety critical 
functions (e.g. applying power to amplifiers). The avionics 
software, including experiment software running on the 
avionics is all considered Class “C”, as defined by NASA 
[11]. The Class C software process entails areas of 
planning, management, design, coding, testing, release, 
maintenance, assurance, and configuration management, 
and monitoring. While these guidelines attempt to be 
comprehensive to aid development and preserve safety of 
the equipment, NASA will work with experimenters to keep 
their development costs to a minimum. In many instances, 
standard company development practices satisfy NASA’s 
development process requirements. 


8. STRS Repository 

Software defined radios present a unique opportunity to 
develop applications that have long term value for NASA. 
A repository will accept software artifacts (e.g. VHDL, 
XML, and documentation) developed for experiments, to 
enable future experimenters access to past applications, 
according to the STRS Architecture. The STRS Repository 
retains software, documents, and ultimately the application 
information so that the application knowledge may be 
passed from one mission to another as missions change. 
Any artifacts and documentation supporting the waveform 
application, including source code, models and algorithms, 
process flow diagrams, and documentation (e.g. design, test) 
are an integral part of the repository. Contributions may 
include proprietary content, or third party software 
components (e.g. IP cores for FPGA), so the repository 
documents the licensing and other usage restrictions. The 
goal is to build a repository of waveforms for NASA’s use, 
while protecting the products and innovation of the 
developers. Figure 8 illustrates the concept of waveform 
submissions. 



Figure 8 - STRS Repository Concept 


Software for the SDRs is considered Class “E+”. This 
designation is a slight modification of the lowest 
classification for mission software, Class E. This 
designation is used for software where the consequence of 
the software failing to meet its objective or operate correctly 
only affects the experiment outcome, but poses little risk to 
the system itself. Software issues within the SDRs are 
generally contained within the SDR and do not pose a 
significant risk to the other parts of the system, unlike the 
avionics. This lower classification eases the development 
burden and in these instances, good engineering software 
development practices will generally comply with the 
requirements. 


The Glenn Research Center verifies that platform software 
and waveform applications comply with the STRS 
architecture and certify the modules submitted to the library 
for future reuse. The STRS architecture will evolve through 
appropriate change process and controls to ensure that the 
architecture continues to meet evolving mission needs and 
allows mission to infuse new technology. 

Individual missions will apply the STRS architecture to 
meet specific requirements and radio development needs. 
Mission designers will determine the implementation 
approach for a particular platform by specifying the 
particular type of radio required, with the set of features and 
operating functions needed to accomplish the mission. The 
missions will tailor the architecture for the specific radio use 
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and implementation while remaining compliant with the 
architecture. The library of software modules provides 
mission designers a starting point for waveform 
applications. Missions will both submit their waveforms to 
the repository or use waveforms from the repository. 
Designers could adapt modules used from the library to 
meet individual requirements and needs reducing their 
project costs. Waveforms used from the repository will be 
shared with appropriate use agreements to protect he 
original developers. Designers will also provide valuable 
feedback to improve the architecture definition for uses and 
accommodate current or available technology. 

Communication radio providers within the space products 
industry will develop architecture compliant radios to meet 
architecture & mission requirements through traditional 
acquisition procedures. The repository offers an 
opportunity to reduce develop costs by allowing developers 
to reuse existing software from NASA’s STRS repository 
and utilize elements of compliant designs over multiple 
missions to reduce radio costs. 


9. SDR Experiment Experience 

Having SDRs in space offers many opportunities for test 
and evaluation of new concepts both for the SDR 
applications and signaling and with the operational use of 
SDR technology. A few of the lessons associated with the 
SDR technology itself include: the SDRs require personnel 
with a wide skill set, SDR flexibility leads to complexity, 
software management includes both space and ground 
assets, characterize SDR platform along with applications, 
and provide a flexible method to add commands and 
telemetry. 

SDR personnel skill set : SDRs are small and compact, yet 
they are complete communication systems. For hardware, 
they often include digital signal processing, up and down 
frequency conversion, transmit or receive RF sampling, 
stable oscillator subsystems, and RF amplifiers. In software 
they include many functions beyond just the “modem”. 
They now include the software infrastructure (such as 
STRS), radio services such as power amplifier monitoring, 
temperature control or protection, file management, and 
others. Applications include traditional modem functions 
such as modulation and encoding, but could also include 
many more software functions such as data framing, 
network routing (e.g. Internet Protocol (IP) or Disruptive 
Tolerant Networking (DTN), and applications using these 
different capabilities. In addition, many of NASA’s 
services conform to the Consultative Committee for Space 
Data Standards (CCSDS), thus requiring additional skills. 
While it’s possible to have the software engineer only worry 
about the infrastructure, they cannot discount what the 
waveform application might require from the platform 
operating environment. The waveform developer must 
understand the RF portions of the platform, to better 


understand their own requirements and needed performance 
along with adherence to any applicable standards. And 
finally, the system engineer needs to oversee the entire link 
end-to-end, with much of the space link processing (in this 
case) within the SDR itself. 

SDR flexibility leads to complexity. While a mission may 
never reconfigure its complete function everyday like the 
SCaN Testbed for obvious reasons, SDRs still provide a lot 
of flexibility which could lead to considerable complexity if 
not managed properly. The entire process of developing 
new software requires a ground unit SDR mostly identical 
to the flight unit. The SCaN Testbed engineering models 
generally used flight parts (for functionality) but with less 
screening (for cost) than the flight radio. Even with these 
measures, an early waveform still experienced peculiar on- 
orbit behavior over temperature, not experienced on the 
engineering model. While the tolerances for temperature 
were designed for the on-orbit ranges, adjustments still had 
to be made. At issue seemed to be how the FPGAs were 
instantiated upon waveform load. Modifying the load 
software along with verifying the instantiation helped 
resolve the problem. 

Software management The software for both development 
of new waveforms (i.e. development tools) and the on-orbit 
waveform or infrastructure software must be carefully 
managed. Software development tools (and sometime the 
development hardware itself) go obsolete long before the 
space hardware fails. This creates issues to have compatible 
development boards and tool chains for new waveform 
development. The array of developers (e.g. infrastructure, 
applications, application integrators) provide multiple 
versions of different software, sometime for each new 
waveform. It’s imperative to use good configuration 
practices, for both ground and flight, and be able to manage 
all combinations (e.g. OE 1 and WF 1, OE2 and WF2, OE2 
and WF1, etc. especially when the OE is part of a waveform 
build). Due to on-orbit anomalies, the project had 
circumstances where it used older versions of infrastructure 
software, but with a newer waveform. This creates an issue 
if one wants to verify by test every combination on the 
ground, versus doing verification by analysis or inspection 
to reduce time/cost to get something on-orbit. 

One way to manage or reduce the complexity with SDRs is 
with new automated functions or adding cognition within 
the SDR to offload operations. The SCaN Testbed plans to 
develop a number of applications (both flight and ground) to 
look at how these new functions such as cognition could be 
useful in a space mission, and what functions make sense to 
perform with the radio. Link management, data 
management, and in the future, spectrum management will 
all be investigated. 

Characterize SDR platform along with applications : 
Platform hardware is generally much more capable than 
what initial waveforms might use initially during a mission. 
SCaN Testbed initial waveforms were compatible with the 
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existing services at Space Network (NASA’s space 
infrastructure), but the project envisioned advancing new 
waveforms for future uses. The requirements for future 
capability must be flowed down to the platform developer 
and the system developer in such a way to document the 
launch capability and understand the performance of the 
radio in the system. Requirements must reflect platform 
capability (not just initial waveforms) for verifications. 
Platform providers could also provide test waveforms for 
the verifications. Having waveform tools for such tasks as 
recording raw ADC samples for post processing (variable 
sample rates, durations, etc), transmitting arbitrary signals 
or perhaps data from a stored file provide significant 
capability once the radio is integrated into the system. 
These tools alone provide transmit and receive capability to 
test the entire system without using a specific modulation 
and coding combination that might be used for the mission. 
In addition, lower level radio services (non-waveform 
software) to measure receiver gain, receive power level, 
transmit power level (may require hardware sensor), and 
frequency tuning are all key items to control or measure. 

Flexible method to add commands and telemetry. Because 
SDRs are reprogrammable on-orbit, there needs to be an 
architecture developed at requirements formulation time to 
add new waveforms and provide a path for the associated 
new commands and telemetry. These requirements may 
have impact on the platform developers. The operations 
centers for space SDRs will originate the commands and 
display telemetry of the SDRs. In the STRS model, new 
waveforms could come from a third party developer who 
needs the platform to deliver their telemetry to the ground 
and they may require new commands be added to the 
platform. Due to the compressed schedule, the SCaN 
Testbed accepted the command/telemetry interface from 
each platform developer “as is”, and it provides an 
opportunity to see three different approaches. The GD SDR 
uses a very efficient, but more stringent command and 
telemetry interface. Bit positions within 1553 structure 
indicate operational modes and telemetry measurements. 
Changing waveforms on-orbit entails changing the 1553 bit 
structure and definition on the radio and within the avionics 
(flight computer). The Harris SDR uses a name value pair 
defined by the waveform application. This provides more 
flexibility for new waveforms, but also introduces 
configuration files to define the name and value pairs. The 
JPL SDR infrastructure provides a few words of telemetry 
(sent to the ground periodically) for new waveforms but 
relies more on a serial console looking interface providing 
text over 1553, with variable size and rate, and a free 
format. While it is most flexible, this now creates a file on 
the ground which is saved separate from the spacecraft 
telemetry data. Thus in all these options, the command and 
telemetry architecture needs to consider the new waveform 
telemetry, how to bring the data down to the ground (with 
spacecraft telemetry or separately), how to store the 
telemetry (filed with spacecraft data or separate), flexibility 
to add telemetry or commands, including updates to the 


command dictionary (both on-board and documentation), 
and overall data management. 

On the ground, for all the radios, screens display telemetry 
from the launch waveforms. New waveform telemetry 
generally requires new screens be developed within the 
ground software to display new telemetry. In some 
circumstances, new raw telemetry may reuse existing 
screens, but will lack any engineering conversion on the 
ground before display. To minimize changes on the ground, 
an architecture that uses perhaps name value pairs, and then 
builds screens based on the new configuration will reduce 
development time and costs for new waveform updates. 


10. Conclusion 

NASA’s SCaN Testbed is a flight communication system 
installed on the external truss of the International Space 
Station. The flight system consists of three software defined 
radios capable of communicating with the Tracking Data 
Relay Satellites of NASA’s Space Network (GEO satellite 
infrastructure), or directly with ground stations located 
anywhere on the Earth within view of 1SS. The system can 
communicate at the S-band or Ka-band frequency. The 
system also has an SDR that receives at the L-band 
frequency to receive GPS or other global navigation satellite 
system signals. 

The unique aspects of the SCaN Testbed allow 
investigations in the environment of space, using fully space 
qualified, radiation tolerant electronics. All aspects of both 
the flight and ground system are implemented and available. 

The SCaN Testbed Project is studying the application of 
SDRs to NASA missions, through experiment use of the 
Testbed. Experimenters from NASA, industry, academia, 
and others are invited to use the Testbed to conduct 
experiments in communication, navigation, and networking 
applications. The experiment applications on the SDRs are 
compliant to NASA STRS Architecture, a common 
architecture for SDR platforms and applications to enable 
waveform abstraction from underlying hardware. The 
enduring nature of software and the common STRS 
Architecture provide a repository of applications to enable 
software reuse among missions employing STRS compliant 
SDR platforms. The SCaN Testbed, and STRS are paving 
the future for NASA’s use and understanding of software 
defined radios for space. 

Lessons learned from operating the SDRs include 
understanding the skill set required for developing and 
operating SDRs, which exceed traditional communication 
radios, understanding how to manage SDR flexibility such 
that it does not lead to additional complexity and cost, 
characterizing the SDR platform along with applications, 
and providing a flexible method to add commands and 
telemetry 
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